fix(connectors): the external feed sync reads membership before it writes (TASK-164) - #1952

Closes the exception #1940's body names: every other connector site reads the strict predicate, and this one read nothing.

The gap

syncExternalFeeds loaded integrations and went straight to the provider. No membership read anywhere in the service, so it could not tell a creator from an ordinary departed member:

• the flag-on path (EXTERNAL_FEED_PERSIST_POSTS=1) wrote posts as integration.createdBy;
• the default path (appendIntegrationBuffer + enqueueCuratorEvents) handed that owner's feed to the pod's curator agents.

createMessage 403s that same owner. The owner can stop being a member without anyone touching the integration — leavePod filters them out of members, agent cleanup $pulls them — and the row kept syncing as them. Found by Wren (74669) while closing TASK-161.

The fix

The read goes before the provider call, at the top of the per-integration body: isListedPodMember(pod, integration.createdBy), the same predicate the pod's own write paths implement. A departed owner therefore makes no provider request, advances no cursor, and writes nothing on either path — buffering and curator events are both behind it.

A pod that is gone pauses too. It cannot name a member, and the alternative (sync into nothing, report success) is the failure mode the row is about. That one is my addition beyond the row's text, flagged here rather than buried.

Pause shape, per Wren: status: 'error' with a Commonly-written errorMessage and errorMessageUserFacing: true, written as its own update rather than thrown into the catch — the catch stamps errorMessageUserFacing: false, which is right for provider text and wrong for copy a person must read. isActive stays true so the row stays on the owner's Connectors page; that page has no action for x/instagram (integrations.ts:681), which is why the copy carries the next step itself. 'error' also takes the row out of the sync query (status: 'connected'), so the pause is written once per connection rather than every tick, and a re-saved row pauses again on the next sync. No resume logic is added.

Admin rows would have paused at birth, which is why this PR also touches the admin route: only the first requester of the Global Social Feed pod became a Mongo member (at pod creation), and a second admin configuring the other feed type was mirrored into PG alone (ensureGlobalPodPostgresSync). ensureGlobalSocialFeedPod now $addToSets the requester into Mongo members — the surface the predicate reads and the pod's own write paths enforce — and hands on the refetched pod. createdBy is untouched: it is the row's owner, not a membership record.

Consumers: schedulerService (two call sites) and the admin /sync route. Both get the same behaviour; the paused entry comes back as paused: true, success: false with the reason as content.

Witnesses (5 new arms, 23 tests in the two suites)

Ledger — 10 mutations, each alone, 9 no-survivor

M2 is a tripwire, not coverage. isListedPodMember already refuses a null pod, so behaviour cannot distinguish the two forms. I kept the clause because relying on a util's nil handling for a pod lookup couples this branch to that implementation detail, and the pod-gone arm reads better for it.

M7 and M10 both redden the controls rather than the departure arms, and that shape is the point. A wrong principal, or reference equality instead of value comparison, pauses everyone — so the arms that can see it are the ones asserting a listed owner is not paused. The departure arms pass under both for the wrong reason, and saying so is more useful than a count.

M10 is why the fixture changed. It survived the first ledger because my pod stub and my integration fixture shared one ObjectId instance, so includes passed by reference. mockPodMembers now stores a fresh instance carrying the same hex, which is what a lean read produces — the arm would otherwise have certified a fixture rather than the code. This is the TESTING.md fixture-shape rule one layer over: the mutation did not fail to apply, it applied and was admitted by the instrument.

Verification

• __tests__/unit/services + __tests__/unit/routes — 300 suites / 2817 tests green.
• Lint: services/externalFeedService.ts and routes/admin/globalIntegrations.ts 0 errors, 0 on touched lines. The two test files are at their main baseline (16 and 12 import/* errors, the repo-wide pattern for .js tests requiring .ts modules, not gated); the new Pod require carries that same pair. Two object-curly-newline violations I introduced by copying the surrounding one-line body: {...} style are fixed — main has one such pre-existing violation at admin.globalIntegrations.test.js:243, untouched.